The Reservoir model and architecture for open federated cloud computing

ion of an SAP system (CI: central instance; DI: dialog instance). 4 : 4 B. ROCHWERGER ET AL. IBM J. RES. & DEV. VOL. 53 NO. 4 PAPER 4 2009 service applications based on a formal contract that specifies the infrastructure SLAs. The same contract should be reused to provision multiple instances of the same application for different tenants with different customizations. Dynamic elasticity—The Reservoir cloud should dynamically adjust resource allocation parameters (memory, processing, network bandwidth, and storage) of individual virtual execution environments seamlessly. Moreover, the number of virtual execution environments must be dynamically and seamlessly adjusted to adapt to the changing load. Automated continuous optimization—The Reservoir cloud should continuously optimize alignment of infrastructure resources management with the high-level business goals. Virtualization technology independence—The Reservoir cloud should support different virtualization technologies transparently. Reservoir model for federated cloud computing In the Reservoir model, there is a clear separation between the functional roles of service providers and infrastructure providers. Service providers are the entities that understand the needs of a particular business and offer service applications to address those needs. Service providers do not own the computational resources needed by these service applications; instead, they lease resources from infrastructure providers that provide them with a seemingly infinite pool of computational, network, and storage resources. Infrastructure providers operate Reservoir sites that own and manage the physical infrastructure on which service applications execute. The federation of collaborating sites forms a Reservoir cloud. To optimize resource utilization, the computational resources within a site are partitioned by a virtualization layer into virtual execution environments (VEEs). VEEs are fully isolated runtime environments that abstract the physical characteristics of the resource and enable sharing. The virtualized computational resources along with the virtualization layer and all of the management enablement components are referred to collectively as the VEE host. A service application is a set of software components that works collectively to achieve a common goal. Each component of such service applications executes in a dedicated VEE. The VEEs are placed on the same or different VEE hosts within the site or on different sites (Figure 3). A service application is deployed on the Reservoir cloud using a service manifest, described later in this section, that formally defines the contract and SLA between the service provider and the infrastructure provider. Resource allocation Within each Reservoir site, the resource utilization is monitored and the placement of VEEs is constantly updated to achieve optimal utilization with minimal cost. Similarly, the execution of the service applications is monitored and the capacity is constantly adjusted to meet the SLA and requirements specified in the manifest. Reservoir supports two modes of capacity provisioning with respect to service providers: explicit and implicit. In the explicit capacity requirements for sized-serviceapplications mode, the service provider conducts sizing and capacity planning studies of the service application Computational resource Computational resource Computational resource Virtualizer Virtualizer Virtualizer VEE host VEE host VEE host Reservoir site 1 Reservoir site 2 Service application 1 Service application 2 Service application 3